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ABSTRACT 



This system protects proprietary software from disclosure 
and unauthorized use, enforces license limits on number of 
users of the software, and prevents corruption of protected 
software by computer viruses. Software protected under this 
system may execute only on computer systems which incor- 
porate a microprocessor capable of deciphering enciphered 
instructions in real time. Program files are first enciphered 
under control of a distribution cipher key. Prior to first use 
of software, program files must be customized on the user 
computer system. This customization procedure 
re-enciphers the programs, so that they are enciphered under 
a second cipher key. Customized programs may not execute 
on a computer system other than one constructed with a 
processor chip which incorporates a crypto microprocessor. 
The crypto microprocessor is capable of performing this 
re-encipherment, and of executing both enciphered and 
unenciphered programs. The customization program runs on 
user's computer system and normally accesses a remote 
Exchange database system by means of a modem to accom- 
plish its task. Variations of customization process provide 
for storage of enciphered software on either a single system, 
a network server, or a site license repository system 

12 Claims, 11 Drawing Sheets 
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OVERVIEW OF THE SYSTEM 

FIG. 1A SOFTWARE VENDOR 
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FIG. 1B HARDWARE REQUIREMENTS 
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FIG. 3 CUSTOMIZATION - NETWORK SERVER MODE 
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FIG. 4 CUSTOMIZATION - SITE LICENSE MODE 
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FIG. 5 CCR AS TRANSMITTED TO EXCHANGE 
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FIG. 6 CCR AS RETURNED TO INSTALL 
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FIG. 7 CRYPTO CONTROL MEMORY 
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FIG. 10 CRYPTO MICROPROCESSOR 
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SYSTEM FOR COMPUTER SOFTWARE 
PROTECTION 

BACKGROUND OF THE INVENTION 

1. Background-Field of Invention 

This invention relates to a system for protecting computer 
software. More specifically, this invention relates to a cryp- 
tographic system for protecting mass marketed software. 

2, Background-Description of Prior Art 

As of this writing more than 100 million microcomputers 
are in use worldwide. Encouraged by this large installed 
base of systems, software developers are creating products 
at a rapid pace, However, one problem threatens the con- 
tinued development of reasonably priced software: software 
piracy, the unauthorized copying of programs. Software 
vendors have dealt with the piracy issue by various means, 
both technical and legal, but it still remains a serious 
problem. The Software Publishing Association, an industry 
group of more than 900 firms, recently estimated that the 
industry loses revenues of $2.5 billion annually due to this 
problem. Although many patents have been issued whose 
purpose is to discourage or prevent software piracy, the 
operational mechanism of many of these patents are too 
complex to be accepted by purchasers of computer software. 
Computer users have come to expect software products to be 
easy to use, else they will not buy them. 

One method for protecting software (now rarely used) is 
copy protection. The terra "copy protected" means mat 
program distribution media (e.g., floppy diskettes) cannot be 
copied by normal means. A diskette is formatted, or mag- 
netically encoded, as concentric rings of bit patterns called 
tracks. Each ring is divided into parts called sectors; nor- 
mally the number of sectors is the same for all tracks. Each 
sector is comprised of a header area followed by a data 
block. A checksum follows, whose value is used to detect 
errors in the recording process, A typical copy protection 
scheme modifies an unused sector after a program has been 
recorded onto the diskette, such that the program may be 
executed without error, and a copy utility will duplicate the 
program without detecting the invalid sector. However, the 
program contains instructions which check the diskette for 
its error sector, and will terminate if loaded from a copied 
disk. 

The use of this protection method led to development and 
sale of numerous "bit copier 1 * utility programs, which, unlike 
standard copy utilities, can produce executable duplicates of 
the programs. Thus, this form of media copy protection 
discouraged but did not prevent software piracy. 

A second approach to software protection is the use of an 
electronic security device, sometimes called a dongle, which 
attaches to one of the computer's external input/output ports. 
Programs which are to be protected in this way must make 
procedure calls which interrogate the port to make sure the 
dongle is in place, and that the dongle has a unique identifier 
which matches the unique identifier embedded in a location 
within the program. If the dongle is not there, or if one is 
attached which has a non-matching identifier, the program 
terminates. U.S. Pat No. 4,609,777 to CargUe (1986) and 
U.S. Pat No. 4,685,055 to Thomas (1987), describe two 
such devices. Various manufacturers of dongle devices con- 
tinue to sell them to software vendors, but most software is 
still sold without these devices, either because of cost 
criteria or lack of acceptance by software purchasers. A 
disadvantage of the hardware dongle protection method is 
the ease with which a determined perpetrator can crack the 
protection algorithm by monitoring the port and bus lines 
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with a storage type data analyzer. Another disadvantage is 
that each software package is typically supplied with its own 
dongle, so that the user might soon run out of ports. 
Additionally, the hardware dongle method does not actually 

5 conceal instruction codes. By using a well-known technique 
(disassembly) a skQled programmer could easily find the 
appropriate interrogation code and disable it 
Protection Criteria 
At a minimum, a software protection method should do 

10 two things: prevent disclosure of the actual program instruc- 
tion codes (whether in source or object form) and restrict the 
use of a software product to the software's purchaser or 
licensee. One approach which promises to meet these 
requirements is the use of the crypto microprocessor. A 

15 crypto microprocessor is a plug-in replacement device for 
the conventional microprocessor, but is capable of executing 
enciphered instructions. An enciphered program may 
execute only on a designated computer system incorporating 
a cryto microprocessor which deciphers the program accord- 

20 ing to a specific cipher key or algorithm. Crypto micropro- 
cessors can be built at reasonable cost since the translation 
circuitry is not unduly complex. In addition, the method 
does not interfere with computer user's customary practices. 
For example, the user is able to copy his software for backup 

23 purposes. Equally important, enciphered software can be 
processed in a manner compatible with current production 
and distribution methods. 

If a method prevents disclosure of program instructions, 
we say it conceals codes. If a method restricts or assigns the 

}0 software to one computer system, we say it assigns a system. 
Table 1 compares protection methods according to these 
criteria. 



TABLE 1 
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Copy protect 
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Yes* 
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Dongle 


No 


Yes* 




Crypto processor 


Yes 


Yes 



*Can be defeated in all cases by means discussed 



Concealment and assignment criteria must be met for any 

45 acceptable protection method, and the comparison above 
shows that only the crypto processor meets both. 

Patents for crypto processors have existed for more than 
a decade, yet no general-purpose devices are currently being 
manufactured. The lack of success for these other 

50 approaches is partly explained by failure to address the 
marketing requirement, stemming from cost and logistical 
criteria, such that software be distributed as standardized, 
non-customized ("shrink wrapped") packages. For a soft- 
ware protection method to attain market acceptance, it 

55 should provide four additional capabilities: 

1) User customization. This means that the purchaser may 
designate the computer system on which the software will 
reside and execute after the sale rather than prior to pur- 
chase. The only alternative to user customization is enci- 

60 pherment by the vendor before its sale. A labor-intensive and 
expensive approach, pre-sale customization is specified in 
U.S. Pat No. 4,633388 to Chiu (1986), which describes a 
microprocessor with a means of selecting one of a set of 
cipher keys for decryption. The microprocessor also sup- 

65 ports execution of both enciphered and unenciphered 
programs, as does VS. Pat. No. 4 ,757,534 to Matyas et aL 
(1988). Although the Matyas et al. patent provides for 
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post-sale customization, the system does not actually 
employ a crypto processor. Instead, enciphered programs are 
stored on disk and loaded into private" memory for execu- 
tion. Decipherment is performed by ROM-resident software 
prior to launching the program. 5 

2) Multiple keys. Use of the same cipher key in a crypto 
microprocessor to decipher all protected programs 
makes it vulnerable to the "known plaintext" attack. 
U.S. Pat. No. 5,034,980 to Kubota (1991) proposed a 
fixed cipher key embedded in each chip. If, for 10 
example, a programmer working for a software devel- 
oper has both a protected version and the plaintext 
version of a program, he could easily determine the 
cipher key of a system on which the protected version 
runs. He could then crack any protected software which j 3 
was subsequently installed on that system. Because of 
this weakness, a crypto processor needs to use a dif- ■ 
ferent key for deciphering each enciphered program. 

3) Network support It is estimated that by the year 1995, 
seven of every ten computer systems will be connected 20 
to a local area network (LAN). In LAN environments, 
programs are typically stored on a file server computer, 
then are loaded from the server's disk drive over the 
network into the main memory of a requesting 
workstation, there to be executed. None of the 
described crypto microprocessors provides for a net- 
work server mode. 

4) Mixed enciphered/nonenciphered code support. 
Because a user is likely to possess programs that are not 
protected under encipherment, he should not lose this 
software investment as a consequence of owning a 
computer using a crypto microprocessor. In fact, with 
today's powerful computers, he will probably want the 
ability to concurrently execute enciphered and nonen- 
ciphercd programs. One approach to mixed mode 
execution would allow the same program to contain 
both enciphered and clear text instructions, implying 
the use of a program means to switch modes, as Chiu 
described in U.S. Pat. No. 4,633388 (1986). This 
method is not suited for mixed support of indepen- 40 
dently developed programs, however. 

A second method would support serial execution of either 
nonenciphered or enciphered programs, but not both modes 
concurrently such as the crypto microprocessor described in 
U.S. Pat No. 4,573,119 to Westheimer et al (1986). The 45 
Westheimer device has a circuit which detects an operation 
code specifying lower and upper bound addresses of enci- 
phered programs. The circuit responds by enabling two 
transform units which decipher the program's instruction 
codes and data addresses within the specified bounds, but a 
branch to a location outside the bounds would result in a 
fault 

Yet another method would allow multiple enciphered 
programs to be run concurrently with nonenciphered pro- 



avoid the weakness of "known plaintext" attack); support of 
a protection mode for operation on a local area network; and 
mixed enciphered/nonenciphered code support of indepen- 
dently developed programs. 
Table 2 compares support of features by these patents, 

TABLE 2 
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Crypto Processors: Comparison of Features 
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no 
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no 
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no 


no 


no 
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yes 


yes 


no 


yes 


no 
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yes 


yes 


yes 


no 


no 
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OBJECT OF THE INVENTION 

Designed to prevent software piracy, the present invention 
comprises a method of enciphering computer programs, a 
method of customizing the programs by the user, an 
improved crypto processor, and a method of execution in a 
computer system incorporating this crypto processor. 
Accordingly, several objects and advantages of the present 
invention are: 

1) Prevent a computer program from being executed on 
computer systems other than those authorized or 
licensed for said program. 

2) Provide a network operating mode, allowing a single 
copy of a protected program to reside on a file server 
system, then loading executable copies to requesting 
workstations, with each workstation having its own 
cipher key. 

3) Provide for user customization of programs, making it 
possible to mass distribute "shrink wrapped" protected 
software. 

4) Remain compatible, insofar as possible, with current 
software production and distribution methods, and with 
the practices of computer users. 

To achieve these and other objects, innovations are intro- 
duced by the present invention to overcome the shortcom- 
ings of the other approaches, including an improved crypto 
microprocessor which incorporates a re-encipherment trans- 
lation means. The crypto functions are encapsulated so as to 
be essentially independent of computer architecture. 
In the described embodiment, protected software is pur- 



chased and is customized by the user to execute only on one 
grams within a single environment but not allow mixing of 55 designated computer system or network. Each computer 



enciphered and nonenciphered modes within one program 
(as in U.S. Pat, No. 5,034,980 to Kubota, 1991). In this 
approach, mode switching is performed by software after 
loading a mode register prior to the dispatch of a process. 
This method is the most flexible for multitasking systems. 

In summary, there are three main approaches to software 
protection: diskette media copy protection, hardware dongle 
devices, and crypto microprocessors. While the crypto 
microprocessor offers the strongest form of protection, pre- 
vious crypto microprocessor patents omitted some important 
capabilities. These include: user customization (to designate 
the target computer system); use of multiple cipher keys (to 



system incorporates a crypto microprocessor which deci- 
phers the program according to a specific cipher key or 
algorithm. The crypto processor is a plug-in replacement 
device for the conventional microprocessor, and existing 
60 non-crypto systems may be easily and inexpensively con- 
verted. 

The object of replacing chips in sockets of existing 
systems also means that the present invention is an extension 
of current computer instruction set architectures, rather than 
65 a totally new one. Thus, one may be able to buy replacement 
chips for the Intel 1APX86, Motorola 68 k, and other popular 
microcomputer families. 
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SUMMARY OF THE INVENTION 
Improved Crypto Processor 

A novel and useful feature of the present invention's 
crypto processor is its ability to re-encipher protected pro- 
grams. That is, it translates a file enciphered under a first 
cipher to a form enciphered under a second cipher. It is this 
feature which lets the user designate the target computer 
system after he buys the software, rather than beforehand (as 
is required by other methods). The procedure in which a 
user's target computer is so designated, and his program files 
are translated to execute only on this computer, is referred to 
as user customization. Some prior crypto microprocessors 
were able to both decipher and encipher programs, and 
therefore could combine these two operations to produce a 
**re-enciphered" file. However, the method using two sepa- 
rate operations can reveal plain text information in a com- 
puter's main memory. In contrast, the present invention 
deciphers and enciphers as a single indivisible operation. 
Since intermediate results are kept within the crypto micro- 
processor chip, plain text cannot be accessed by the user. 
Thus a program may be translated from one cipher to a 
second cipher in the user*s target computer system, at his 
own workplace, without compromising proprietary program 
codes. 

A further benefit provided by the re-encipher operation is 
support of a network operation mode. In this mode, enci- 
phered programs are maintained on a file server computer 
system, but are made available for loading over the network 
for execution on any eligible network-attached workstation. 
Since each workstation via its crypto microprocessor is 
assigned a unique cipher key for each program that may be 
requested, the re-encipher operation is used to translate from 
the server cipher key to the assigned workstation cipher key. 
Thus on a network with 100 workstations, only one copy of 
a program is stored rather than 100 copies with each 
program copy enciphered differently. 

The re-encipher operation also enhances the crypto micro- 
processor's ability to render protected programs tamper- 
proof. The method employed is to encipher program files 
using the cipher block chaining (CBC) method, described by 
Federal Standard 1026, proposed by the U.S. General Ser- 
vices Administration. The last cipher block of the program 
is effectively a checksum of all preceding program blocks, 
providing a means for detecting file modification. The CBC 
checking will normally be incorporated into the operating 
system's program loading functions. As willful corruption of 
the program can always be detected by this means, most 
computer viruses cannot infect enciphered programs. 
Software Development 

Software developers who make use of the present inven- 
tion will find that their work remains essentially unchanged. 
However, whenever a software product is ready for release, 
a developer will perform two additional steps: 

1) Contact a remote EXCHANGE database system to 
transmit software product release information, includ- 
ing: software vendor identifier, product name and 
version, and number of product copies, either by serial 
number range or by enumeration. The EXCHANGE 
system will respond to this information by specifying a 
cipher key and cipher algorithm with which the soft- 
ware developer is to encipher the software product 
prior to duplication and distribution of copies. 

2) Encipher a master copy of the software product under 
the cipher specified by the EXCHANGE system. This 
master copy will be used by the developer's duplication 
department or a service bureau as the source copy for 
duplication. 
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User Customization 

A user who intends to obtain software protected under this 
invention must either have a computer system incorporating 
the described crypto microprocessor, or must upgrade his 

5 system by installing a crypto microprocessor in his system. 
After the user purchases a copy of the protected software, he 
installs it on his own system from the distribution media. 
This is common practice for almost all software now, and 
normally entails copying and/or decompressing programs 

10 from distribution media (e.g., magnetic diskettes or optical 
CD-ROM disk). However, a software product which is 
protected under the present invention requires that the user 
perform an extra step. The aforementioned remote 
EXCHANGE database system is contacted as a part of 

is software installation. The user executes a customization 
program which prompts the user for input parameters. A 
control message is then transmitted to the EXCHANGE 
system. The EXCHANGE system sends a reply with data 
which enables the customization program to modify the 

20 programs to a form which may be loaded and executed on 
the target system. 

BRIEF DESCRIPTION OF THE DRAWINGS 
To further aid in understanding the invention, the attached 
drawings help illustrate specific features of the invention. 

25 The following is a brief description of the attached drawings. 
FIG. 1 is an overview of the system; FIG. 1A shows the 
software vendor role, FIG. 1 B shows the computer user 
hardware requirements, FIG. 1C shows user installation and 
customization of protected software. 

30 FIG. 2 shows user customization for single system mode. 
FIG. 3 shows user customization for network server 
mode. 

FIG. 4 shows user customization for site license mode. 

FIG. 5 shows the layout of a customization control record 
35 (CCR) as sent by INSTALL to the EXCHANGE system. 

FIG. 6 shows the layout of a customization control record 
(CCR) after it is returned by EXCHANGE to INSTALL. 

FIG. 7 shows the layout of crypto control memory. 

FIG. 8 shows the format of a Cryptix executable program 
40 file, together with its loaded process image. 

FIG. 9 is a block diagram of the Cryptix dynamic library 
processing. 

FIG. 10 is a block diagram of a crypto microprocessor. 
FIG. 11 is a block diagram of a crypto translation unit 
45 FIG. 12 is a block diagram of the cipher key generator. 

DETAILED DESCRIPTION OF THE 
INVENTION 

50 Consideration of the following example, which is purely 
exemplary, further clarifies the use of the invention. 

Enciphered programs are distributed in the same manner 
as unenciphered software, recorded onto magnetic, optical, 
or other media such as diskettes, tape cartridges, CD-ROMs, 

55 semiconductor memory cards, and etc. Programs may also 
be transferred over the switched public telephone network 
by modem, or over a digital data network. The fact that a 
program is protected under the present invention is trans- 
parent to a software user. That is, the program behaves in 

50 execution exactly the same as its unprotected version. 
However, the user is unable to share protected software 
freely with others, except as described later, since it is 
capable of execution on one and only one designated com- 
puter system, 

65 Referring to FIG. 1-A, program files 10 created by a 
software developer are enciphered under a distribution 
cipher key 12 before being sent to a duplication facility 14. 
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The duplication may be done in-house or by a service existence of a SYS ED. The EXCHANGE need not be 
bureau. In either case the program codes are safe from contacted if a SYSID already exists, 

unauthorized disclosure. After duplication, the software dis- The CRYPTO JNI File 

tribution media 16 are packed with documentation and other Three kinds of entries arc held in CRYFTO.INI: the 

materials, wrapped in a colorful package, and shipped to 5 SYSED, the target system's DEVID(s) ; and the SYSIDs of 

outlets for eventual sale. eligible client systems if the target system is a network 

FIG. 1-B illustrates the requirement that the user's com- server. The term NEITD is used to denote the SYSID of a 

puter system must incorporate a crypto processor 18 in order client system, to distinguish it from the server SYSID. 

to execute protected software. A protected software package The first entry of the CRYFTO.INI file contains the 

will not run on any system other than the designated target 10 system identifier: 

computer 20, and will not do so until a user customization SYSID 

procedure is executed. For eac h crypto processor of a system, an. entry is stored 

User Customization j n the CRYFTO.INI file of the form 

After a software package is purchased, the user must DEVID (Ed(SYSKEY) ) 

customize the software with an installation procedure before 15 whcre DEV1D fa thc dcyice idcDtmcr afld mSYSEEY) 

the protected programs can be executed on a designated deaQtes ^ m d her k end hered under ^ device 

target computer system. C^ercustonuzaUon (FIG 1-C) is ci her k corresponding t0 DEVID. By referencing its own 

performed by running an INSTALL program which is nor- ^ SQr ^ access to the SYSKEY, 

rnaUy provided on the attribution media 16. NETTD entries are stored in the form 

To ensure that a purchased software package is installed 20 ^rprm m fWPTKTTYl •» 

onto a designated computer system and no other, the 1 ktJ^ a . .{ evem t i- -ui i 

INSTALL program acts in cooperation with a remote ™ here tfEnD denotes ^1™^^° ^ 

EXCHANGE database system. The EXCHANGE database computer system, and Es^ETKETO denotes the SYS- 

rctains records on every software package protected under "e^U^^? Unte ^ JT^* 

this invention, information provided by software vendors 25 system SYSKEY. NETTO entnes arecreated d = » 

prior to them distributing the protected programs. In ment of a s J stem s ^^i^i^^ 011 ^^ 

addition, the EXCHANGE database holds information f provides fte valuesfor Es(NETKEY) from a list of 

describing crypto microprocessor parts distributed by hard- 2F^^ U " i?'* ^ STMJL - 

ware vendors The EXCHANGE Database 

Identifiers and Cipher Keys 30 ^ EXCHANGE database comprises four main kinds of 

tables * 

Each crypto microprocessor part is fabricated with non- 

volatile read only memory (ROM) cells which permanently me 0) HARDWARE table and its child the (2) DEVICES 

store a device identifier (DEVID) and a device cipher key uble > and & e ( 3 ) SOFTWARE table and its child the 

(DEVKEY). A protected computer system is assembled ( 4 ) PROGRAMS table, 

using these microprocessor parts. The operating system 35 The HARDWARE table is essentially a catalog listing of 

provides a service so that programs may obtain the DEVID 311 microprocessor types, The DEVICES table is 

of any of its microprocessors. more ^ 30 inventory file, enumerating every crypto pro- 

A computer system based on crypto microprocessors has cessor extant The SOFTWARE table like the HARD- 

in addition a system identifier, or SYSID, and a system WARE toWe ' is anions to a catalog, but of protected 

cipher key or SYSKEY. Support of crypto functions can be 40 software products. The PROGRAMS table is an inventory of 

provided only by protected (enciphered) versions of the protected software program packages which have been 

operating system (OS). After installation of the OS, but prior shipped by distributors. 

to installing and executing other protected software, the OS As noted i DEVICE records exist for all parts 

installer contacts the EXCHANGE network to request manufactured, each record containing the relation: 

assignment of a system identifier (its SYSID) and a system 45 DEVICES (DEVID*, SYSID*, DEVKEY, SYSKEY), 

cipher key (or SYSKEY) for the computer. The OS installer where DEVED and SYSID are marked with an asterisk * to 

may be the computer system manufacturer (many of whom indicate they are lookup keys. SYSID and SYSKEY are 

pre-install operating systems) or the end user. The SYSID either empty (meaning the device is not yet assigned a 

will be used to identify the user's system in all future system identifier), or have the values assigned by the 

installations of protected software; the SYSKEY is used to 50 EXCHANGE software during operating system installation, 

encipher protected software during installation, and to deci- Software developers licensed to protect their program 

pher program files during program execution. products under this invention must provide the 

After the EXCHANGE has assigned the SYSID and EXCHANGE database with an enumeration of every soft- 

SYSKEY, the operating system stores the SYSID on a disk ware package before they are distributed for sale. The data 

file with filename CRYFTO.INI, and also records it into 55 provided by the software developer comprises program 

nonvolatile system memory. Either an EEPROM memory or name and program version; a list or range of serial numbers 

a battery-backed CMOS memory chip may be used to store an< * associated user counts of each must also be specified, 

the SYSID, In the event that the SYSID is lost from the disk where the user count denotes allowed number of computers 

file where it was stored, it may be recovered from its which may concurrently execute the program under terms of 

nonvolatile memory location, or vice-versa. If a loss of the 60 ^e License agreement. 

SYSID occurs in both memory chip and the disk file, the The EXCHANGE database will then be extended by 

EXCHANGE software can restore it from a table look up of creating an entry in a SOFTWARE table of the form: 

any of the DEVJDs. Note that the SYSID is normally not SOFTWARE (SID*, SNAME, DISTKEY) 

needed except when installing protected software; the where SID denotes the generic identifier for the software 

SYSID is unrelated to the computer system manufacturer's 65 package (including version); the asterisk * indicates it is a 

serial number. Should a second protected operating system table lookup key. The SNAME field contains me official 

be installed, the installation program will check for the product name, and DISTKEY is the distribution cipher key 
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under which the program files are enciphered A related set depending on the system where the files reside (repository 
of entries will be inserted into a child table called system) and also depending on the designated system or 
PROGRAMS, each entry having the form: systems on which the programs may run (execution system). 

PROGRAMS (PGMID*, COUNT, SYSID), In single system mode, the files reside on the same system 

where PGMID is marked by * to indicate it is a lookup key; 5 whereon the program executes. In network server mode, the 
it denotes the program identifier, a composite value made up program files reside on a server system and are executed on 
of the SID (defined in the SOFTWARE table), and a serial network-attached workstations. In site license mode, the 
number unique for each package shipped. The COUNT field program files are installed on and reside on a primary 
is the user count or number of concurrent executions; it is repository system. These files are then duplicated onto 
usually 1 but may be greater than one if the package is 10 removable media as archive or backup copies; the media are 
installable on a network or is the master (site or corporate) removed from the repository system and are manually 
license copy. The SYSID is a placeholder, since the software transported to and restored onto secondary computer sys- 
is as yet uninstalled. The EXCHANGE database reserves a terns. The secondary systems are also eligible to execute the 
physical location in each record of the PROGRAMS table programs. The number of such systems may be limited by a 
for SYSID, as this field will eventually receive the system 15 maximum licensed user count. 

identifier of the target computer on which the program is FIG. 2 shows the user customization procedure, 
installed. INSTALL first reads a customization control record (CCR) 

Customization by INSTALL/RESPONSE from a diskette 16. The system identifier (SYSID) of the 

Installation of protected software is managed by an target computer 20 is then obtained from an operating 
INSTALL process running on the target computer system in 20 system service; the SYSID is moved into the CCR. Under 
cooperation with a RESPONSE process on the control of the INSTALL program, target computer 20 then 
EXCHANGE database system. INSTALL initiates the com- contacts the remote EXCHANGE database System 24, 
munication and transmits a customization control record which returns the updated CCR with data obtained from 
(CCR) to the EXCHANGE: table lookups using the PGMID and SYSID. 

CCR (ICODE, SYSID, COUNT, PGMID) 25 In network server mode (shown by FIG. 3), the INSTALL 

is sent to the EXCHANGE system to request user customi- procedure is very much like single system mode. However, 
zation where ICODE=7 (denoting single system mode), the COUNT value in the CCR message sent to the 
SYSID is set to the target system identifier, PGMID is set to EXCHANGE may be greater than the number of processors 
the product identifier of the subject software, and COUNT= in the repository or server computer, so that network- 
1, as the target computer has only one processor. The 30 attached client systems are eligible to load and execute the 
EXCHANGE system receives this message, acknowledges subject protected programs in site license mode (shown by 
it and passes the data to a RESPONSE process which FIG. 4), wherein the software is stored on a primary reposi- 
perf orms a lookup of the PGMID in one of the PROGRAMS tory computer, archive or backup copies may be prepared on 
tables. Assuming PGMID is found, the data record is read: removable media for restoring on other eligible computer 

(PGMID, PGMKEY, COUNT, SYSID). 35 systems. Each archive copy so created causes the site user 

If the record SYSID field is empty, RESPONSE process count to be incremented by one. The INSTALL program 
compares the record COUNT field with that of the INSTALL l°gs the creation of each copy and will not allow copies to 
message COUNT value. If the latter is not larger than the exceed the maximum user count, as specified by the terms 
former value, the INSTALL COUNT is used to replace the of me site license. The archive files are restored under 
record COUNT and the INSTALL SYSID is moved into the 40 control of an INSTALL program on the receiving system, 
record SYSID field. The RESPOND process then reads the which customizes the software for its SYSID. 
DEVICES table to obtain the SYSKEY value for this Hardware Upgrades 

SYSID. This SYSKEY is used to encipher PGMKEY. Protected software is customized for execution on desig- 
RESPOND then formats the message: nated repository and execution systems; however, the user 

CCR (RCODE SYSID COUNT PGMID 45 should be able to contmue usmg such custonuzed software 
Es(PGMKEYJ) ' after upgrading his computer system hardware. To accom- 

where Es(PGMKEY) denotes the PGMKEY enciphered modatc processor chip or system board replacement (or a 
under SYSKEY. This message is returned to the INSTALL complete system upgrade), the UPGRADE program allows 
process the user to rc-customize software by specifying appropriate 

The table below lists the values and descriptions for the 50 °P tions - For example, if a processor chip or system board is 
ICODE and RCODE parameters: replaced in a computer with software customized for single 

system mode, the user executes the UPGRADE program. 
UPGRADE will make a copy of the CRYPTO JM file, 
naming the copy CRYFTO.NEW. UPGRADE then displays 
55 a dialogue box asking the user to specify his new configu- 
ration. 

If one or more microprocessors are to be removed or 
replaced, the DEVTX) of each device are deleted from the 
CRYFTO.NEW file. For each replacement microprocessor, 
60 and any microprocessors that are added to the system, 
UPGRADE inserts the DEVIDs into the CRYFTO.NEW 
file. This done, UPGRADE then contacts the EXCHANGE 
system and requests appropriate upgrade data, which com- 
prises DEVID/Ed(SYSKEY) entries for each client proces- 
65 sor upgraded, and NETTD/Es(NETKEY) entries far each 
Protected software is customized in one of three basic server processor upgraded. If the EXCHANGE returns this 
modes: single system, network server, or site license, data without error, the CRYPTO. NEW file is updated. After 
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8 
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die hardware change is complete and the upgraded system is 
powered up, the operator specifies CRYPTO.NEW as the 
alternate crypto control file. 
Programming Model 

Crypto microprocessors fabricated according to the 
present invention are capable of concurrently executing both 
enciphered and non-enciphered programs. In a uniprocessor 
system, only one task or process may execute at any instant, 
and is referred to as the active process. Multitasking oper- 
ating system software maintains an inventory, usually called 
a ready list, of processes eligible for execution. To efficiently 
handle program decipherment in multitasking and interrupt 
processing environments, a described embodiment of the 
crypto microprocessor employs protection zones, numbered 
0 to N. An area in protected memory containing structures 
called zone management records are used to control deci- 
pherment of up to N programs concurrently. Each enci- 
phered program on a system's ready list is assigned to a 
protection zone, where the zone is identified by a number. 
By convention, normal unenciphered programs are assigned 
to zone 0, enciphered programs are assigned to zones 2 
through N, and in the special case of interrupt handling 
routines, zone 1 controls decipherment: A zone can be 
assigned to more than one process, if the zone management 
record contents are saved whenever a process is suspended, 
and are then restored before the process is resumed. 
Crypto Function Calls 

Below are the crypto functions which together provide a 
programmic interface to crypto services. All functions 
require that their callers execute in privileged mode (also 
called kernel mode). Crypto functions are implemented as 
an extension of the host computer instruction set These 
functions, together with crypto execution mode, contain the 
necessary functionality to fully implement all the features of 
a crypto microprocessor. 



Function 


Mnemonic 


Description 


1 


INTT 


Tntttafo* crypto mode 


2 


READ 


Read zone management record 


3 


SAVE 


Save zone management record 


4 


OPEN 


Open specified zone 


5 


LOAD 


Load crypto status register 


6 


STOR 


Store crypto status register 


7 


INFO 


Get system/device identifiers 


8 


CONY 


Convert (recipher) a code block 



It should be understood that the mnemonic words used for 
the crypto function calls (INTT, READ, etc.) are exemplary 
only. In actual use the words would be replaced by character 
strings that do not conflict with reserved words of the 
operating system programming language. 

The INTT crypto function initializes four data items in 
crypto control memory, the DEVID, DEVKEY, SYSID, and 
SYSKEY. DEVID and DEVKEY values are shifted from 
noncontiguous read-only memory (ROM) cells into their 
respective registers. The ROM cells reside on the crypto 
processor chip as does the crypto control memory area. Note 
mat the DEVID and DEVKEY registers are cleared during 
system RESET. The SYSID and SYSKEY values, unlike 
DEVID and DEVKEY, are not initialized from device ROM. 
but instead are taken from main storage locations pointed to 
by the INTT call parameter list. Operating system software is 
responsible for reading the two values from external storage 
and placing them into main memory. The SYSKEY param- 
eter is enciphered under DEVKEY while in main memory; 
it is deciphered before loading into the SYSKEY register of 
crypto control memory. 

The apparent redundancy of having a RAM DEVKEY 
register which is initialized from ROM cells is an important 
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security feature: had the DEVKEY been made a permanent 
ROM register instead, it would be more vulnerable to 
disclosure, using techniques such as scanning the chip with 
an electron microscope. A perpetrator will have much more 
5 difficulty cracking the secrets of a chip in which a (cipher 
key) register value disappears upon being powered down. 

An operating system routine calls the INTT crypto func- 
tion prior to launching the first enciphered programs. An 
enciphered program may not be assigned to a protection 
zone before the INTT crypto function is activated without 
causing a program fault. Operating system code executed 
after the fist INTT call should be enciphered 

The SAVE crypto function is used by operating system 
routines to transfer a main memory image of a zone man- 
agement record to its appropriate zone table entry within 
15 crypto control memory. The SAVE function is used to 
initialize a zone management record prior to launching 
programs assigned to its zone. The READ crypto function is 
used to transfer a zone management record from its crypto 
control memory entry to a specified main memory location. 
20 The contents of a record remain unchanged in crypto control 
memory. 

The OPEN crypto function activates a zone, allowing 
decipherment of programs assigned to it. A program 
assigned to a zone which has not been OPENed will result 
2 5 in a fault condition when the program is launched 

The LOAD crypto function transfers the contents of the 
specified crypto status register from a main memory loca- 
tion. The STOR function transfers it back into a main 
memory location. Typical uses of STOR and LOAD by 
operating system routines are to retrieve, modify, and then 
transfer a register contents back into crypto control memory. 

The INFO crypto function is used when the SYSID is 
required, such as during install of protected software. As 
explained under the section on user customization, the 
SYSID is used as a table look-up key by EXCHANGE 
3 5 software to obtain the processor's SYSKEY. The SYSKEY 
enciphers data required by user customization. 

The CONV crypto function is used o re-encipher a block 
of data. That is, the data block is deciphered under one 
cipher key and then enciphered under a second cipher key. 
40 It has two modes of operation: CBC mode, which converts 
the data block by using the Cipher Block Chaining (CBC) 
algorithm, and XOR mode, which converts using the simple 
exclusive-OR (XOR) operation. CBC and XOR enciphcr- 
ment are discussed under Cipher Methods, supra. The modes 
45 may be mixed in a given call to CONV: the input block may 
be translated in either CBC or XOR mode, then translated to 
an output block using either mode. 

CONV uses a pair of 256-bit cipher keys, one for the input 
(decipher) operation, and a second key for the output or 
encipher operation. The two cipher keys are passed to 
50 CONV in a parameter list The key parameters in memory 
are enciphered under the SYSKEY to protect against pos- 
sible disclosure. The CONV function parameter list has the 
following layout: 

Parameter 1 (4 bytes): address of input buffer 

Parameter 2 (4 bytes): address of output buffer 

Parameter 3 (4 bytes): length of buffers 

Parameter 4 (4 bytes): initial virtual address 

Parameter 5 (32 bytes): enciphered input base key 
60 Parameter 6 (32 bytes): enciphered output base key 

The internal circuits for implementing crypto function 
calls are not specified, on the premise that each processor 
type will use an appropriate means. In some computer 
architectures the crypto functions may be microcoded 
6S instructions. In others they may be ROM-resident program 
procedures in a processor's standard instructions. If the latter 
means is used, it is important that these functions execute 
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within an exclusive memory space so that they can only be 
invoked via the crypto call interface. Crypto functions 
implemented in this way should be stored as enciphered 
code, to discourage "reverse engineering" the chip design. 
Crypto Control Memory 

HG. 7 shows the layout of Crypto Control Memory. 
Located completely within the crypto microprocessor chip 
itself, this area cannot be accessed by processes executing in 
main memory, including operating system routines. Its 
address space is local to the crypto translation unit logic and 
to the callable crypto functions. 

Crypto Status Word 0 is a 32-bit structure containing data 
items which are initialized by operating system software by 
means of the INIT crypto function call. The high order eight 
bits (bits 31-24) comprise the Program Zone Selector, which 
specifies the Zone Management Record controlling deci- 
pherment of the active program. Closely related to this is the 
Interrupt Zone Selector, an eight bit value (bits 23-16 of 
CSW 0) which denotes the Zone Management Record 
controlling decipherment of interrupt routines. The Crypto 
Disable signal (controlled by bit 7 of CSW 0) globally 
disables crypto functions if reset, enables them when set 
Bits 6-4 encode the Crypto Delay Size; this specifies the 
number of instruction blocks which will be executed without 
decipherment after an interrupt occurs. The Crypto Page 
Size is set into CSW 0 bits 3-5); this is the size in bytes of 
a memory page that will be deciphered under one cipher 
base key. When the Crypto Translation Unit detects that a 
page boundary has been traversed, it generates a new cipher 
base key, which is described in more detail, supra. 

Crypto Status Word 1 is a pointer to the Zone Records 
Semaphore; it is used to control concurrent access to the 
zone management records table in Crypto Control Memory. 

Crypto Status Word 2 is a pointer to the Conversion 
Workarea Semaphore. It is used to control concurrent access 
to the data conversion workarea table in Crypto Control 
Memory. These work areas are used by the CONV Crypto 
Function Call, described in the previous section. 

Crypto Status Word 3 is the Crypto Functions Vector 
Table. This is a table of entrypoint addresses used by 
processor, chip logic to access crypto function calls. 

The DEVID field is a 64-bit structure used to identify a 
microprocessor device. Trie high-order 32 bits conform to 
the device identifier code specified in the boundary scan 
interface described by IEEE Standard 1149-1-1990. The 
low-order 32 bits are a serial number of the individual part 
No two parts having the same device code may use the same 
serial number. Note that a very useful extension of the bound 
scan functions could be used to deter theft of both micro- 
processor chips and systems constructed from them: if the 
built-in self test (BIST) which runs at power up or reset is 
extended to include loading program registers with the 
device identifier code and serial number, these values could 
be displayed whenever the operating system is re-booted. A 
prospective purchaser could check the values to determine 
whether they were among any reported as stolen, and take an 
appropriate action according to the result of the check If the 
microprocessor chip had not yet been incorporated into a 
computer system, it could also be checked by means of a test 
access port readout to see if the chip was stolen property. 

The DEVKEY is a 128-bit cipher key used by operating 
system software to encipher parameters during user cus- 
tomization of protected programs; this cipher key is also 
used subsequently by operating system routines for loading 
the programs for execution. 

The crypto microprocessor performs special handling for 
architectures using interrupts. An interrupt provides a means 
for switching the processing context, replacing the program 
counter with a new value after saving its previous contents. 
Whenever an interrupt occurs, the processor saves the cur- 
rent program counter on the stack (or local memory where 
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the processor has no stack), then loads a new program 
counter value to begin executing a program code to handle 
the specific interrupt cause, usually changing to privileged 
mode. An interrupt occurs whenever certain instructions are 

5 executed, or if certain bus control signals are activated by 
external hardware. Because interrupts may occur thousands 
of times per second in the course of normal processing, do 
delay must be introduced by crypto circuitry in switching 
from decipherment of normal program code, to that of 

10 interrupt handling routines. This performance requirement is 
met by an immediate switch to an alternate protection zone 
when the Crypto Translation Unit detects that an interrupt is 
in progress, and is explained in greater detail, supra. The 
same performance criteria are met in the switch back to the 

15 interrupted program, after the interrupt has been serviced. 
Operating System Support 

A programming interface using a set of callable crypto 
functions is provided to support loading and execution of 
protected programs. The crypto functions serve to isolate 

20 system software from underlying hardware 
implementations, allowing for future extensions without 
creating incompatibilities. Protected programs must be 
launched with the assistance of the operating system, since 
only privileged programs may execute the crypto functions. 

25 Operating system support on crypto microprocessors is 
discussed below using as an example the Cryptix operating 
system, a version of System V UNIX having extensions for 
enciphered program files. The present invention supports 
other operating systems such as MS-DOS, WINDOWS, 

30 UNIX and others by extending these operating systems 
using the following described techniques as examples. 
Launching Programs 

A program file is an executable file residing on a disk 
volume. Cryptix reads a program file into memory and then 

35 executes it by means of the exec system call. An executing 
instance of a program is called a process. The program file 
is loaded by exec into memory in a form referred to as the 
process image. 
FIG. 8 shows a program file disk structure 810 with its 

40 process image 830 after the exec function has read it into 
main memory. This information is based on the UNIX 
System V Common Executable File Format (COFF) defi- 
nition. Cryptix files, like those of standard UNIX, begin with 
a file header 812. This structure holds a data item (f 13 flags) 

45 which indicates whether or not the file is executable. 

Following the file header is an auxiliary header 814 which 
contains information used by the UNIX exec system call to 
load the file into memory. The auxiliary header found in 
Cryptix executable file formats is compatible with the stan- 

50 dard COFF but has definitions used by the system to support 
enciphered program files. Far clarity, item names here may 
depart from standard UNIX names. 



AUXILIARY HEADER STRUCTURE 





SHORT 


Runtime object format 


vstamp 


SHORT 


Optional version stamp. 


tsize 


LONG 


Size of machine code in bytes. 


dsize 


LONG 


Size of initialized data in bytes. 


bsize 


LONG 


Size of uninitialized data in bytes. 


entry 


LONG 


Program entry point address. 


txt_base 


LONG 


Runtime base of program code. 


database 


LONG 


Runtime base of program data. 


bss base 


LONG 


Runtime base of uninitialized data. 



65 The first auxiliary header item, with the whimsical name 
magic, denotes the object format of the file. Four values are 
defined for unenciphered program formats: 
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OMAGIC 407 Impure; text segment is writable. 

NMAGIC 410 Shared; write protected text segment. 

ZMAGIC 413 Special format used for demand loading. 

LffiMAGIC 443 Shared library of same format as ZMAGIC. 5 



Cryptix defines and supports the four enciphered versions 
of these formats: 

10 

OCRYPITC 607 Enciphered OMAGIC format file. 

NCRYPTIC 610 Enciphered NMAGIC format file. 

ZCRYFTIC 613 Enciphered ZMAGIC format file. 

LIB CRYPTIC 643 Enciphered UBMAGIC format file. 



Existing non-crypto UNIX systems will not attempt to 
load protected programs having these new magic identifiers 
but instead will return an error. 

Again referring to FIG. 8, a variable number of section 20 
headers 816 follow the auxiliary header 814. Each section 
header describes one of the sections contained in the pro- 
gram file. Of the twenty or more section types, program files 
usually contain only a few, the most common being the .text, 
.data, and .bss sections, exec reads these sections into 25 
memory, loading corresponding text region 834 and data 
region 836 into the process image 830. 

Cryptix adds one new section type, denoted by the name 
".key". The key section 822 holds a cipher key table for an 3Q 
associated text section 820. The cipher key table is a set of 
initial or seed values used to generate working cipher keys 
during execution of enciphered code. If a cipher key table is 
present, a .key header must be the first section header in the 
file, since its contents are needed to load subsequent pro- 35 
gram text 

As an example, suppose the exec system call is invoked 
by an executing process. The caller passes two parameters, 
returning an INT result 

40 

errcode=exec( filename, args); 
where filename denotes a pointer to a character array that is 
initialized with the name of the enciphered file, args denotes 
a pointer to a string of zero or more comrnand-line program 
arguments, and err code is the INT type result. 45 

exec first reads the file header into memory. If the f_flags 
item has value F_EXEC set on (0002 hexadecimal), 
this denotes the subject file is executable, exec saves 
the f_flags information, then reads the auxiliary header ^ 
814 into memory. 
The magic item in the auxiliary header is checked; if it has 
one of the values (407, 410, 413, 443), exec recognizes this 
is an unenciphercd file and branches to the normal program 
load logic. On the other hand, if magic is one of the values 55 
(607, 610, 613, 643), the kernel routine which handles 
enciphered program loading receives control. Any other 
value for magic results in an error, returning a non-zero 
result (errcode) to the caller. 

Suppose the magic item was ZCRYFHC 613): This value 60 
indicates exec must call the CONV crypto function to 
re-encipher the program code in addition to normal text 
loading. If this is the case, exec reads the first section header 
following the auxiliary file header, which must describe a 
.key section. 65 

The .key section header has several items used to manage 
the loading of enciphered program files: 



s_namc 


CHAR 


Section name (".key"). 


s paddr 


LONG 


Physical address of cipher key tabic. 


SLjvaddr 


LONG 


Virtual address of cipher key table. 


s_size 


LONG 


Section size in bytes. 


s_scriptr 


LONG 


File pointer to cipher key table. 



If s„name is not equal to ".key", exec returns an error to its 
caller. If equal to ".key", exec allocates an area to store the 
cipher key table (using s_size plus an allowance for any 
dynamic library routines to be loaded). A parameter list to 
call the CONV crypto function is then built. As each text 
block is read into storage, exec updates the parameters as 
required and calls CONV to re-encipher the program text 
CONV is called with parameters indicating CBC decipher- 
ment and XOR encipherment, with dynamic key generation. 

Before the program is launched, a protection zone is 
assigned to it by calling the OPEN crypto function. This 
initializes the assigned zone management record with the 
starting cipher key and the program base address. Crypto 
mode will be enabled by the system process dispatcher upon 
activating the program, to allow decipherment of the execut- 
ing program This is done by resetting bit 31 of Crypto 
Status Word 0. 
Shared Libraries 

Cryptix also supports dynamic calls to shared library 
procedures, wherein the tibrary is either unenciphered, or is 
enciphered under a different cipher key than the calling 
program. As in standard UNIX systems, host library proce- 
dures are bound with the calling program, resulting in .lib 
sections and .init sections in the executable file. The code in 
the host procedures generate a system call (dynex), which 
acts to mediate a dynamic linkage to a shared target library 
procedure. 

FIG. 9 diagrams Cryptix dynamic library processing. A 
target library file has a magic code of UBMAGIC (443) for 
Unenciphered text, or UBCRYFIIC (643) for enciphered 
text. If the library file has not been loaded, dynex allocates 
a library text region 933 aligned on the next even multiple 
of 1 MB after the program text region 834, and loads the 
library text section 920 into it If the target library is 
enciphered, this allows dynex to set the target library cipher 
key(s) into the next sequential location in the calling pro- 
grams cipher key table; dynex will request the CONV 
function to re-encipher the library text, making it a seamless 
continuation of the calling program so that it executes under 
the same protection zone. 

However, if either the library file is enciphered and the 
calling program is not, or vice-versa, the library text cannot 
execute under the same protection zone as the calling 
program. For this reason, dynex sets up a zone-switching 
mechanism. In cases where both calling program and library 
procedure are enciphered, or where both are unenciphered, 
dynex resolves the call reference directly: i.e., the calling 
program loads the procedure address in the fixed-up code. In 
cases where the calling program is enciphered and the target 
library is unenciphered, or vice-versa, dynex fixes up calling 
program code so that a system call (to dynex) is made to 
mediate the linkage each time. On each such call, dynex 
saves the current zone identifier and switches to a new one, 
allocating and initializing a zone management record to 
control execution of the library procedure. On return to the 
caller, another dynex call is madeto de-allocate the zone 
management record and set the zone identifier to that of the 
caller. 

Protected Driver Program 

Before protected software may be installed on a computer 
system, the system must (1) be fitted with a crypto 
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microprocessor, (2) be assigned a system identifier or 
SYSID by the EXCHANGE system, and (3) have a pro- 
tected driver program. 

The protected driver is needed because all but one of the 
crypto functions (the COT call) can be called only from 
enciphered code. The functions are further restricted by the 
fact that calling programs must also run in privileged mode. 
The user customization procedures accompanying the 
INSTALL program for protected software, do not execute as 
privileged code. Hence, a privileged interface to the crypto 
functions is needed, in the form of an installable driver. 

The "installable" attribute means the driver is loaded by 
the operating system as a memory-resident routine, but is not 
directly callable by user application programs. Instead a 
calling program may only access the driver by means of a 
software interrupt instruction, which causes a mode switch 
to privileged execution. On return to the caller, execution 
mode switches back to non-privileged. The protected driver 
program is enciphered by the EXCHANGE using a cipher 
key unique to the target system; the program file is down- 
loaded on the occasion of its the initial contact with the 
EXCHANGE to obtain a SYSID. 
Cipher Methods 

Cryptographers have long known that simple ciphers such 
as substitution or modulo-2 addition can be as secure as 
more complex techniques, provided that a sufficiently long 
non-periodic random cipher key is used, To be perfectly 
secure, a key must not contain any repeating characters or be 
used to encipher another message. A cipher using such a key 
stream is called a one-time pad. These are the only ciphers 
that achieve perfect secrecy, and were in fact used by the 
Soviet KGB organization. The method originated in 1917, 
when Gilbert Vernam devised a cipher based on the Baudot 
alphabet of the AT&T teletypewriter. In a Vernam cipher, 
letting M=ml m2 . . . denote a plaintext bit stream and K=kl 
k2 . . . a key bit stream, the generated ciphertext bit 
stream=C=Ek(M)=cl c2 . . . , where 

ci=(mi+ki) mod 2, i=l>2 

This cipher is implemented in a microprocessor using the 
"exclusive-or" operation, where any ciphertext bit ci=XOR 
(mi, ki). The cipher is reversible: mi=XOR(ci, ki). 

EXAMPLE: 

If plaintext character A (01000001 in ASCII) is added 
modulo-2 to the key character R (01010010 in ASCII), the 
result is: 



M = 01O0000l (unenciphered character "A") 

K = 0 1 0 1 0 0 1 0 (key character a R") 

C = 00010011 (enciphered character "A"). 



The one-time pad is the model used for the described 
embodiment of this invention for a crypto microprocessor. If 
unenciphered program text is divided into multiple blocks 
and a different key is generated for each block, the large key 
size requirement is satisfied. Our problem is reduced to the 
task of designing a generator of random non-repeating key 
blocks. 

Encipherment during Software Production 

Protected programs are distributed as files enciphered 
under a set of keys stored within the program file, in an array 
referred to as the cipher tey table. The cipher key table is 
itself enciphered under a 128-bit distribution key, the 
PGM KEY. The PGMKEY is stored in the SOFTWARE table 
entry for the subject program, within the EXCHANGE 
database. The instruction text portion of program files are 
enciphered under a cipher having the properties: 
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Ek(B)=B where k=0, 
Ek(B) NOT=B where k NOT=0, 
where Ek(B) denotes the encipherment of plaintext data 
block B under the cipher key k A function which satisfies 

5 these properties is modulo-2 addition, implemented on com- 
puters as the exclusive-OR (XOR) operation. 

Although any function satisfying the aforementioned 
properties could be used, the example here employs XOR. 
The XOR operation is combined with cipher block chaining 

10 (CBC) to protect against modification of the file, as defined 
by proposed Federal Standard 1026. 
Encipherment during User Customization 

User customization re-enciphers the protected programs 
under a transformed set of keys. The transform consists of 

15 applying the Data Encryption Standard (DBS) algorithm 
using 56-bit keys extracted from the DEVKEY of the 
ins tallin g crypto processor. If KL is used to denote the 
low-order 56 bits of DEVKEY, KH denotes the high-order 
56 bits of DEVKEY, and Bn denotes an arbitrary block of 

20 the cipher key table, transform T is calculated as: 

Tl=DES(KL3n) 

T2=DES(KH,T1) 

T=DES(KL,T2) 
25 The transformed cipher key table is then enciphered under 
SYSKEY using the same procedure, substituting SYSKEY 
for DEVKEY in the expressions. Note that the DES algo- 
rithm is used as a non-linear transform under the DEVKEY, 
whereas encipherment under the SYSKEY is done for 
30 concealment The instruction text section of the program file 
is enciphered using exclusive-OR operations on each block 
with cipher block chaining (CBC) to protect against modi- 
fication. 

Encipherment during Program Launch 

35 Operating system functions which are used to launch 
protected programs must re-encipher the programs. Both 
decipherment and encipherment are under the SYSKEY, but 
use different algorithms. The program code is deciphered 
from XOR/CBC and then enciphered under XOR without 

40 CBC, since program execution requires random access. 
While in main memory the program code no longer needs 
the CBC protection; memory management facilities suffice. 

Thus it is seen that programs protected under the present 
invention are enciphered at three different times: (1) prior to 

45 distribution, (2) during user customization, and (3) during 
program launching. 

Program execution makes use of one kind of cipher 
algorithm, while program storage under distribution and 

5Q user customization ciphers use another kind. Each of these 
cipher techniques is chosen as the optimal one for its special 
purpose, but the ultimate object is to prevent disclosure or 
misuse of protected software. 
The method used to encipher distribution and user reposi- 

35 tory files is modulo-2 addition with cipher block chaining 
(CBC), which is similar to the well-known cipher feedback 
mode. A new cipher key is generated by the CBC technique 
by combining the current block key with the last enciphered 
data block. The CBC method reduces vulnerability to cryp- 

^ tographic attack because the original cipher key is diffused 
throughout the cipher text CBC algorithms also generate 
check sums which can be used to verify whether the file has 
been modified. The Vernam cipher described earlier used a 
bitwise XOR operation; however, since the CBC method 

65 enciphers blocks of data, the ith plaintext block Mi is 
enciphered as 

Ci=XOR((XOR(Mi, K», Ci-1) 
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where initial riphertext block Co=XOR(Mo. K); K is the 
cipher block key. Deciphering is done by computing 

Mi=XOR((XOR(Ci, Ci-1)),K) for i>0. 

While distribution and repository ciphers benefit from the 
cipher block chaining technique, CBC cannot be used as a 5 
cipher for program execution. Because an executing process 
accesses its instructions randomly rather than sequentially, 
decipherment of a block must not depend on the contents of 
a prior block. For this reason, our execution cipher uses 
modulo-2 addition without chaining. 10 
Crypto Translation Unit 

FIG. 10 is a diagram of a crypto microprocessor con- 
structed according to the present invention. For illustrative 
purposes, the described embodiment uses a conventional 
Intel486™ microprocessor with the addition of a crypto 15 
translation unit 1008, connected to the primary on-chip 
instruction cache unit 1010. A32-bit linear address bus 1046 
connects a segmentation unit 1022, a paging unit 1024 and 
a cache unit 1010. A 20-bit physical address bus 1045 
connects paging unit 1024 to cache unit 1010. 20 

During program execution, the miaoprocessor execution 
unit 1020 generates requests for instruction fetches as well 
as data operand accesses to main memory. These memory 
read requests are in the form of segmented addresses, which 
are expressed as the implied sum of a segment register value 25 
and an offset value. Segmentation unit 1022 translates the 
segmented address into a linear address, which expresses a 
location encoded as a 32-bit integer value. This value is also 
referred to as the virtual address or logical address. If paging 
mode is enabled in the microprocessor, linear addresses are 30 
mapped to physical addresses by means of tables held in 
unmapped memory. Paging unit 1024 performs the transla- 
tion to physical address, either by a table lookup or by 
referring to a translation lookaside buffer (TLB) 1026, which 
holds a set of the most recently translated addresses. While 35 
this mapping and translation of linear to physical pages is 
complex, it allows storage of data and instructions in non- 
contiguous physical locations. 

After an instruction fetch generates a segmented address, 
the address is translated to a linear value, and the paging unit 40 
uses two levels of tables to translate the linear address into 
a physical address. The first table level is the page directory, 
which is a 4 k-bytc table of 32-bit entries. Each directory 
entry holds a 20-bit page number which specifies a 4 k-byte 
second level page table containing 32-bit entries which point 45 
to physical page frames. The hardware paging mechanism 
indexes into a page table during address translation using the 
linear (logical) address as a lookup argument The result is 
the high-order 20 bits of the physical address. The low-order 
12 bits are the same for both logical and physical addresses. 50 

To compensate for the performance penalties incurred in 
both address translation and fetching data and instructions 
from main memory, the miaoprocessor stores frequently 
used logical/physical address pairs in the on-chip translation 
lookaside buffer (TLB) 1026 and stores frequently accessed 55 
data and instructions in the on-chip 8-KB unified cache 
buffer 1012. 

In most cases the page-mapped address is resolved by an 
entry in the translation lookaside buffer or TLB 1026, which 
translates the logical address to a physical memory address. 60 

Paging unit 1024 transfers the high-order 20 bits of the 
physical address (referred to as the physical tag) to on-chip 
cache unit 1010 via physical address bus 1045; the low order 
12 bits of the address are obtained from linear address bus 
1046. 65 

An instruction fetch is always requested from cacheable 
memory. The linear (logical) address and the 20-bit physical 
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tag are latched into cache unit 1010 during a memory read. 
The instruction will be supplied from the cache if a cache hit 
occurs on the read address (the physical tag plus the page 
offset). Any instruction bytes read from the on-chip cache 
are in unenciphered form, having been deciphered when the 
cache line was first filled from external memory. If the 
address is not in the cache, a cache line fill request is 
signaled to bus interface unit (BIU) 1002 with read address 
on internal address bus 1032. The BIU complies by driving 
the external bus with an instruction read bus transaction. 

External logic decodes the control and address signals, 
enabling main memory to respond with code (instructions) 
in 32-bit blocks. The BIU 1002 transfers the code blocks via 
internal code bus 1033 to crypto translation unit (CTU) 1008 
where they are assembled into 128-bit cache lines. 

Signals internal to the CTU indicate whether the code 
blocks fetched are enciphered. If a cache line is not enci- 
phered it passes unchanged from the CTU to cache unit 1010 
where a cache line is filled. The instruction bytes requested 
(that initiated the cache fill) are then moved over code bus 
1036 to prefetch unit 1004. The prefetch unit has a 32-byte 
queue which actually comprises two 16-byte lines of code; 
while one line is in use the prefetch unit fills the other line. 

FIG. 11 is a diagram of the Crypto Translation Unit, which 
is the heart of this invention. A common clock signal and a 
common data bus (neither shown) are shared among the 
functional blocks of the CTU. An instruction translation 
cycle is initiated by the assertion of the code-available signal 
1142 from bus interface unit 1002 (of FIG. 10). This signal 
is presented to both decipher logic 1106 and crypto key 
generator 1110. The cipher key generator 1110 then loads a 
sequence of input terms from the zone management record 
in control of the currently-executing process. If signal 
interrupt-in-progress 1132 is active, the interrupt zone man- 
agement record provides the input terms. If the signal 1132 
is inactive the program zone management record controls 
decipherment, and its input terms are used. 

Referring again to FIG. 11, when an interrupt handling 
routine is active (i.e., interrupt-in-progress signal 1132 is 
asserted), multiplexor 1112 passes the interrupt zone byte 
1124 (from CSW 0 of FIG. 7) to address decoder 1114, 
selecting interrupt zone record 1118 in zone control RAM 
1116. On the other hand, if the interrupt-in-progress line 
1132 is inactive, this indicates that a normal (non-interrupt) 
program is executing, and multiplexor 1112 passes program 
zone byte 1122 (from CSW 0 of FIG. 7) to decoder 1114 
instead. Decoder 1114 uses the low-order 6 bits of the zone 
selector (either 1124 or 1122) to address of one of the zone 
management record structures within zone control RAM 
1116 (i.e. interrupt zone record 1118 or program zone record 
1120). Cipher key generator 1110 loads the data words from 
the selected zone record, using each word as an input term 
to generate active cipher key 1104. After key generation is 
complete, cipher key generator 1110 asserts signal key- 
available 1140. Coincident with the signal code-available, 
(which started the cycle), key-available causes decipher 
logic 1108 to decipher the instruction line. The decipher 
logic block contains a modulo-2 adder (exclusive-OR 
operation). The translation cycle completes when assertion 
of text-available 1144 signals that deciphered code is avail- 
able to the instruction decode stage. 

1\vo other signals may be present as outputs from mul- 
tiplexor 1112: zone-disable 1136 and zone-delay 1138 these 
are passed through directly to cipher key generator 1U0 
rather than going to address decoder 1114. The two signals 
are controlled programmatically by operating system soft- 
ware according to the two high order bits of interrupt zone 
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byte 1124 and program zone byte 1122 (in Crypto Status 
Word 0). If zone-disable signal 1136 is asserted during 
generation of a cipher key, the cipher key generator 1110 sets 
active cipher key 1104 to zeros* bypassing access of zone 
control RAM 1116. If signal zone-delay 1138 is asserted 
during generation of a cipher key, the cipher key generator 
1110 sets active cipher key 1104 to zeros for the duration of 
Di instruction lines, where Di is a value encoded in bits 4-6 
of Crypto Status Word 0. Zone control RAM 1116 is not 
accessed by the cipher key generator 1110 after zone- delay 
1138 is detected, and the signal is reset at the end of Di 
instruction lines. In either case when active cipher key 1104 
is set to zeros, the signal key-available 1140 is asserted. 

The signal crypto-disable 1134 is controlled by setting bit 
7 of Crypto Status Register 0. Whereas signal zone-disable 
1136 disables decipherment only for the currently executing 
task, the crypto-disable signal 1134 disables crypto func- 
tions for the entire system. If crypto-disable 634 is made 
inactive by reset of bit 7 of Crypto Status Register 0, cipher 
key generator 1110 loads active cipher key 1104 with zeros 
during key generation cycles, acting to globally disable all 
crypto functions, including that of instruction decipherment. 
If bit 7 of Crypto Status Register 0 is set, normal crypto 
operations resume. 
Cipher Key Generator 

The described embodiment employs a multi-stage cipher 
key generator. The design requires a complex computation 
to be performed periodically, but this overhead is interleaved 
with other operations to improve performance. 

Because the cipher method is reversible, a key generated 
for deciphering program code must be the same as was used 
for enciphering. To simplify key generation, the executable 
code portion of a protected program is divided into logical 
base segments of 1 MB size. Since it is likely the program 
is not an exact multiple of 1 MB, the last base segment may 
be short. Each base segment is denoted by a relative number 
0, 1, 2, . . . and has an associated 128-bit "seed" or base key 
referred to as BASEKEY 0, BASEKEY 1, and so on. The 
BASEKEY n values are stored as an enciphered array in the 
program file, and this array is loaded into memory when the 
program is to be executed. 

Each 1-MB program base segment is further divided into 
512 2-KB pages. Each page is associated with its own page 
cipher key. Whereas the base keys are stored on disk and 
loaded into memory when the program is executed, page 
keys are computed by the cipher key generator as required, 
using the base key of the current base segment as a seed 
value. The base number Bn is used as an input term for the 
page key computation. Page keys are 128 bits long; 
however, page keys are not used directly for deciphering 
code. Each page key is used to compute up to 128 line keys, 
a line being the unit of decipherment in this example, 16 
bytes. A line key is used only once; a new line key is 
computed for each 16-byte instruction line. 

Since the base number Bn, page number Pn } and line 
number Ln are input terms used by the key generation 
algorithm, the crypto translation unit must obtain their 
current values before initiating a key generation cycle. 

FIG. 12-A is a diagram of a 32-bit digital address with 
base number, page number, and line number. The base 
number is encoded in address bits 29-20 (10 bits), allowing 
for programs as large as 1024 MB. The page number is 
encoded in address bits 19-11 (9 bits) permitting 512 2 KB 
pages per base segment The line number is encoded in 
address bits 10-4 (7 bits), giving 128 lines (16 bytes each) 
per 2 KB page. 

Referring to FIG. 12-B, a key generation cycle is initiated 
by activating the code-available signal 1142. If signal 
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crypto-disable 1134 is active, the operating system has 
globally disabled crypto execution mode. If signal zone- 
disable 1136 is active, the operating system has disabled 
crypto execution mode for the active protection zone. In 

5 either case the cipher key generator simply clears the active 
cipher key 1104 and activates signal key-available 1140. 
Otherwise, the code-available signal initiates generation of 
a new line key. 
Assume a program has been launched under a protection 

10 zone and the operating system has called the OPEN crypto 
function on its behalf. The OPEN function moves program 
protection parameters (base key 1202, line tag 1206) into the 
assigned zone management record. Because the page key 
1204 has not been generated for this program, the line 

15 number and page number in the line tag were both cleared 
to zeros. This forces re-generation of the page key as well as 
the line key. 

After the zone becomes active, the cipher key generator 
sequencing logic 1214 is signaled via code-available when 

20 an enciphered line 1102 is loaded from cache unit 1010 
(FIG. 10). The line tag of this enciphered line is simulta- 
neously loaded into new tag register 1208. Tag comparator 
1214 compares the values of base number and page number 
in new tag register 1208 and line tag 1206. If the base 

25 numbers differ, signal base-mod is activated. If the page 
numbers differ, signal page-rood is activated. 

If the compare caused base-mod to be activated, an 
interrupt is generated, and a code value is placed on the 
interrupt handler's stack indicating the cause for the inter- 

30 rupt. The value of new line tag from register 1208 is also 
placed on- the stack. The interrupt handler interprets the 
cause code, then using the base number from the saved line 
tag, locates the corresponding base key within the cipher key 
table in main memory. This base key value is then moved 

35 into base key 1202 of the zone management record by 
calling the SAVE crypto function. The page-rood signal is 
activated if the page number Pn of the new line tag has 
changed. When this occurs the sequencing logic 1214 begins 
computation of a new page key. Since the new and old page 

40 number values will initially compare unequal, a new page 
key must be computed before the cipher key generator can 
generate a line key. 

A new page key is computed by first loading page key 
1204 from base key 1202. (FIG. 12), Shifter/extractor 1216 

45 extracts the page number from new line tag 1208. This 
ordinal value is taken as the number of bits for aright logical 
rotation of page key register 1204. The result is transformed 
by nonlinear transform 1218, and this further result is shifted 
right by the ordinal value of the base number, completing 

50 computation of the page key. 

To compute the line key corresponding to the line number 
of the (new) line tag 1208, the contents of page key register 
1204 are moved into line key register 1212. The shifter/ 
extractor 1216 extracts the line number of new line tag 

55 register 1208 and performs a right circular rotation of the 
line key 1212 by as many bits, completing computation of 
a line key. The cipher key generator then outputs this key to 
the active cipher key register 1104 (of FIG. 11) and asserts 
the key-available signal to notify the CTU of cycle comple- 

60 tion. 

The foregoing algorithm generates random, non-repeating 
cipher keys for programs up to 256 megabytes in size. If 
required, appropriate parameter changes could increase this 
value. 

65 The cipher method of this embodiment of the present 
invention is illustrated further in pseudo code form, using 
the assignment operator =, and the functions XOR 
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(modulo-2 addition), ORD (extract bits as ordinal), RRC 
(rotate right circular), and NLT (the nonlinear transform of 
the Data Encryption Standard (DES) algorithm). Signal 
variables page-crossed, code-available, zone-disable, 
crypto-disable were described previously; the pagekey, 
linekey, basekey, and devkey variables are register names 
holding the respective key values. 



Page key computation: 

IF page-crossed 

AND NOT (crypto-disable OR zone-disable) 
{ 

pagekey = segmentkey ; 

temp = ORD( pagenumber ) ; 
pagekey = RRC( temp, pagekey ) ; 
pagekey = NLT( cpukey, pagekey ) ; 

temp = ORD( basenumber ) ; 
pagekey = RRC( temp, pagekey ) ; 
} 

END; 

Line key computation: 

IF code-available 

AND NOT (crypto-disable OR zone-disable) 
{ 

linekey = pagekey ; 

temp = ORD( line number ) ; 
linekey = RRC( temp, linekey) 

} 

END; 
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Decipherment of Cipher Keys 

Cipher keys stored in a computer systems main memory 
are always enciphered under the DEVKEY of the CPU 
executing the protected program. The crypto functions INIT, 
READ, SAVE, OPEN, and CONV decipher these enci- 
phered keys into private memory of the crypto micropro- 
cessor. The algorithm used to decipher these keys is a variant 
of the Data Encryption Standard (DES). The DES uses a 
56-bit key, while the method in this embodiment uses two 
56-bit keys, Kl and K2. The enciphered key is first deci- 
phered under Kl, then under K2, then again under Kl. The 
successive application of the DES using two keys is signifi- 
cantly more secure than a single key or just using dual keys. 

This specification should not be taken as limiting the 
invention to a single microcomputer instruction architecture 
nor to detailed operations as described. Other embodiments 
of the invention will be apparent to those skilled in the art 
after considering this specification or practicing the dis- 
closed invention. Hie specification and examples above are 
exemplary only, with the true scope of the invention being 
indicated by the following claims. 

I claim: 

1. A system for restricting the execution of a computer 
program comprising: 

means for re-enciphering the computer program from a 
first cipher forms stored on a distribution media to a 
second cipher form during initial installation of said 
program onto a predetermined storage means of an 
authorized computer system 

wherein said second cipher form is unique to the autho- 
rized computer system; 

means for loading the computer program in said second 
cipher form onto the computer system; and 

means for executing the computer program on the autho- 
rized computer system. 

2. The system of claim 1 wherein said means for 65 
re-enciphering a computer program during installation com- 
prises: 



means for sending information identifying said computer 
program and said authorized computer system to a 
remote exchange database system, said computer sys- 
tem having a system cipher key, wherein said remote 
database system returns a program cipher key unique to 
said computer program, and wherein said program 
cipher key is itself enciphered under said system cipher 
key; 

means for receiving said enciphered program cipher key 

from said remote database system; and 
means for translating said computer program into a sec- 
ond cipher form unique to the authorized computer 
system wherein said translating means is a function of 
said program cipher key and said system cipher key. 

3. The system of claim 1 where said execution means 
comprises: 

a microprocessor including means for generating an 
execution cipher key, said generating means having 
said system cipher key as an input term and further 
including means for combining said computer instruc- 
tions with said execution cipher key under a decipher- 
ing function, such that unenciphered and executable 
computer instructions are accessible to the micropro- 
cessor but are not externally accessible. 

4. The system of claim 2, wherein: 
said executing means comprises: a microprocessor 

including means for generating an execution cipher 
key. 

5. The system of claim 1 wherein said loading means 

comprises: 

means for reading successive portions of said program in 
said second ciphered form into said computer's main 
memory; and 

means for translating said successive portions wherein 
said translating means deciphers then enciphers said 
successive portions in one indivisible operation. 

6. A system for restricting the execution of a computer 
program comprising: 

means for re-enciphering a computer program from a first 
cipher form stored on a distribution media to a second 
cipher form during initial installation of said program 
onto predetermined storage means of a file server 
wherein said second cipher form is executable only on 
authorized computer systems attached to said server, 
means for loading said program from said file server onto 

the authorized computer systems; and 
means for executing said program on the authorized 
computer systems. 

7. The system of claim 6 wherein said loading means 
50 comprises: 

means for reading successive portions of said program 
into the main memory of the authorized computer 
systems; and 

means for translating said successive portions wherein 
said translating means deciphers then enciphers said 
successive portions in one indivisible operation, 

8. A method for restricting the execution of a computer 
program comprising the steps of: 

enciphering a computer program in a first cipher form 

stored on a distribution media; 
initially installing said program in a computer system 
having a crypto microprocessor by perfoming the steps 
of: 

obtaining data from a remote exchange system; 
re-enciphering said program from said first cipher form 
to a second cipher form by translating said program 
with said crypto microprocessor an said data; and 
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storing said program onto storage a predetermined 
means of the computer system in said second form; 
and 

transferring said program from the predetermined storage 
means to the computer system, deciphering said pro- 5 
gram from said second cipher form to a deciphered 
form with said crypto microprocessor, and executing 
said program in said deciphered form 

9. The method according to claim 8 wherein said crypto 
microprocessor deciphers and enciphers the program in a 10 
single indivisible operation. 

10. The method according to claim 9 wherein: 
said computer system has a system cipher key; 

said remote exchange system only releases said data upon 
receipt of said system cipher key; 
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said data includes a program cipher key; and 
said re-enciphering from said first cipher form to said 
second cipher form is performed by a translation func- 
tion utilizing said system cipher key and said program 
cipher key. 

11. The method according to claim 9 wherein the com- 
puter system executes said program in successive portions 
wherein said successive portions are deciphered, executed 
and then enciphered in one indivisible operation. 

12. The method according to claim 11 wherein said 
successive portions are re-enciphered from said second 
cipher form to a third cipher form, then deciphered and 
executed, 

***** 
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